3GPP has defined the Policy and Charging Control (PCC) architecture to allow the Quality of Service (QoS) control and differentiated charging per service data flow. The latter is defined as the user plane packets in the access that match a certain PCC rule.
A separate node, the Policy and Charging Rule Function (PCRF) is a functional element which is responsible for activating the appropriate PCC rule for each access. It encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards a Policy Control and Enforcement Function (PCEF). The PCRF receives session and media related information from an Application Function (AF) and informs the AF of traffic plane events.
The AF is an element offering applications in which service is delivered in a different layer (e.g., transport layer) from the one the service has been requested (e.g., signalling layer), the control of IP bearer resources according to what has been negotiated. One example of an AF is a P-CSCF of an IM Core Network (CN) subsystem. The AF shall communicate with the PCRF to transfer dynamic session information (e.g., description of the media to be delivered in the transport layer). This communication is performed using the Rx interface.
The PCEF encompasses service data flow detection (based on the filters definitions included in the PCC rules), as well as online and offline charging interactions (not described here) and policy enforcement. Since the PCEF is the one handling the bearers, the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. This functional entity is located at the Gateway (e.g., GGSN in the GPRS case, and PDG in the WLAN case). For the cases where there is PMIP instead of GTP protocol between BBERF and PCEF, the bearer control is done in the BBERF instead.
The PCRF shall provision PCC Rules to the PCEF via a Gx reference point. The PCRF shall inform the PCEF through the use of PCC rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decision(s). The 3GPP Rel-8 architecture is illustrated in FIG. 1. The architecture will not be described in detail here. Further information regarding the architecture can be received by studying the 3GPP project.
The PCC architecture has been defined in 3GPP without considering the failover and recovery mechanisms of the involved entities. 3GPP specifies the failover and restoration mechanisms for most of the core network elements in 3GPP TS 23.007. However, PCC architecture has been, so far, out of the scope of this specification. There is some work in 3GPP to incorporate PCC in future versions.
On the other hand, 3GPP has analyzed different PCRF failover and recovery scenarios that are documented in 3GPP TR 29.816. 3GPP TR 29.816, solutions 3 (graceful termination of services), solution 4 (strict termination of services) and solution 9 (unified solution for termination of bearer services) describe a tear-down procedure on the PCRF clients for bearers/sessions for which the PCRF control would be required but cannot take effect, due to PCRF failure or unreachability.
Solution 9 is a merger between solutions 3 and 4 and consists of a mechanism where the PCRF may provide a grace time (with values between 0 and infinite) to indicate the PCRF client when the service/bearer/PDN connection has to be disconnected once the PCRF client has detected that the PCRF is unavailable. The grace time will be provided during the Diameter session establishment. FIG. 2 is taken from 3GPP TR 29.816 and describes the solution 9.
The same TR also provides a mechanism (see e.g., solution 5 and 8) so that one recovered PCRF can retrieve the session data that was being handled before the failure from a client. In order to do so, the client(s) should be up-to-date with all dynamic session data that the PCRF was handling when it was active.
These solutions consider that the PCRF is able to recover PCC rules, access data and other session related information previously stored in a client (e.g., PCEF) so that it can recreate the active sessions without discontinuing the service.
However, the solutions do not consider that the session data would become obsolete since it has not been updated during the time the PCRF has been unreachable. When the PCRF has restarted, PCC control will be lost. The clients (BBERF, PCEF & AF) will have to take different actions depending on the operator policies. Even if the PCC control is recovered (e.g., the Gx/Gxx session is reestablished), the PCC control reestablishment for certain services is not always possible.
For predefined services (i.e., those that the PCRF controls without AF interaction), recovery of PCC control will be possible by retrieving all the session information needed for deriving the applicable PCC/QoS rules for that session. In order to do so, the PCRF needs to retrieve the current access data (e.g. location information, RAT type, IP-CAN type etc.) and the related subscriber information (stored in a non-volatile data base, either in an internal or external repository). The PCC control can be reestablished by different means (e.g. the PCEF may initiate new IP-CAN session establishment for that session).
For dynamic services (i.e., those that are dynamically established based on AF interaction), it is however not possible to reestablish the previous AF session unless the AF contacts the PCRF and provides all the related service data. For current AF-related services (e.g. IMS), this is not feasible. For IMS services, the P-CSCF will only interact with the PCRF upon a user equipment (UE) interaction and will provide the UE provided media information. Since the P-CSCF is a proxy, the previously negotiated session data might not be stored and thus recovered. Therefore the PCRF will not have enough information to derive the PCC rules related to certain AF session.
For this kind of AF-related services (voice calls, streaming, etc.), it is expected that the operator will permit the continuity of the service, to allow the user to have a good perception of the service, even though the PCC control is not reestablished. PCC control in this case will be based on the local policy information that the BBERF/PCEF received before the PCRF failure.
Grace timers set to infinite allow keeping the service active. However, since the AF session cannot be reestablished, there is no mechanism to release the reserved resources once the service is terminated by the calling parties naturally. FIG. 3 illustrates the described problem. Bearers are remained according to previous AF info. There is no mechanism to terminate that bearer when the service is finished (AF cannot notify the PCRF).
In summary, depending on the nature of the service, APN, or operator policy, operators might be interested in: recovering dynamic PCC control whenever possible; terminating current services and keeping only PCC control for new established sessions; keeping certain services active until the UE decides to terminate them when PCC control cannot be recovered for AF-related services; etc.
This flexibility is not possible today.
The flexibility that allows the operator to configure how the PCRF client would behave upon a PCRF failure and recovery does not exist today. 3GPP TR 29.816 describes how to provide grace timers to indicate if the session or service shall be terminated as soon as possible or not. The same TR indicates some mechanisms to retrieve session data from the client once the PCRF is recovered. But it is not possible to indicate whether the client should try to reestablish the previously created Gxx/Gx sessions for certain UE or APN. It is not possible either to indicate the actions to be taken by the PCRF client when the PCC control is not reestablished for certain services.